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Content Distribution Network Interconnection (CDNI) Problem Statement 
Abstract 


Content Delivery Networks (CDNs) provide numerous benefits for 
cacheable content: reduced delivery cost, improved quality of 
experience for End Users, and increased robustness of delivery. For 
these reasons, they are frequently used for large-scale content 
delivery. As a result, existing CDN Providers are scaling up their 
infrastructure, and many Network Service Providers (NSPs) are 
deploying their own CDNs. It is generally desirable that a given 
content item can be delivered to an End User regardless of that End 
User's location or attachment network. This is the motivation for 
interconnecting standalone CDNs so they can interoperate as an open 
content delivery infrastructure for the end-to-end delivery of 
content from Content Service Providers (CSPs) to End Users. However, 
no standards or open specifications currently exist to facilitate 
such CDN Interconnection. 


The goal of this document is to outline the problem area of CDN 
Interconnection for the IETF CDNI (CDN Interconnection) working 
group. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6707. 
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1. Introduction 


The volume of video and multimedia content delivered over the 
Internet is rapidly increasing and expected to continue doing so in 
the future. In the face of this growth, Content Delivery Networks 
(CDNs) provide numerous benefits for cacheable content: reduced 
delivery cost, improved quality of experience for End Users (EUs), 
and increased robustness of delivery. For these reasons, CDNs are 
frequently used for large-scale content delivery. As a result, 
existing CDN Providers are scaling up their infrastructure, and many 
Network Service Providers (NSPs) are deploying their own CDNs. 


It is generally desirable that a given content item can be delivered 
to an EU regardless of that EU's location or the network they are 
attached to. However, a given CDN in charge of delivering a given 
content may not have a footprint that expands close enough to the 
EU’s current location or attachment network, or may not have the 
necessary resources, to realize the user experience and cost benefit 
that a more distributed CDN infrastructure would allow. This is the 
motivation for interconnecting standalone CDNs so that their 
collective CDN footprint and resources can be leveraged for the 
end-to-end delivery of content from Content Service Providers (CSPs) 
to EUs. As an example, a CSP could contract with an "authoritative" 
CDN Provider for the delivery of content, and that Authoritative CDN 
Provider could contract with one or more downstream CDN Providers to 
distribute and deliver some or all of the content on behalf of the 
Authoritative CDN Provider. 


A typical end-to-end content delivery scenario would then involve the 
following business arrangements: 


o A business arrangement between the EU and his CSP, authorizing 
access by the EU to content items controlled by the CSP. 


o A business arrangement between the CSP and an "authoritative" CDN 
Provider where the CSP mandates that the CDN Provider perform the 
content delivery on behalf of the CSP. 


o A business arrangement between the Authoritative CDN Provider and 
another (or other) CDN(s) where the Authoritative CDN may delegate 
the actual serving of some of the content delivery requests to the 
other CDN(s). A particular case is where this other CDN Provider 
happens to also be the Network Service Provider providing network 
access to the EU, in which case there is also a separate and 
independent business relationship between the EU and the NSP for 
the corresponding network access. 
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The formation and details of any business relationships between a CSP 
and a CDN Provider as well as between one CDN Provider and another 
CDN Provider are out of scope of this document. However, this 
document concerns itself with the fact that no standards or open 
Specifications currently exist to facilitate such CDN Interconnection 
from a technical perspective. 


One possible flow for performing an end-to-end content delivery 
across a CDN Interconnection is described below: 


o The initial content request from an EU's User Agent is first 
received by the authoritative (upstream) CDN, which is the CDN 
with a business arrangement with the CSP. 


o The authoritative (upstream) CDN may serve the request itself, or 
it may elect to use CDN Interconnection to redirect the request to 
a Downstream CDN that is in a better position to do so (e.g., a 
Downstream CDN that is "closer" to the EU). 


o The EU's User Agent will "follow" the redirect returned by the 
Authoritative CDN and request the content from the Downstream CDN. 
If required, the Downstream CDN will acquire the requested content 
from the authoritative (upstream) CDN, and if necessary the 
Authoritative CDN will acquire the requested content from the 
Content Service Provider. 


The goal of this document is to outline the problem area of CDN 
Interconnection. Section 2 discusses the use cases for CDN 
Interconnection. Section 3 presents the CDNI model and problem area 
being considered by the IETF. Section 4 describes each CDNI 
interface individually and highlights example candidate protocols 
that could be considered for reuse or leveraging to implement the 
CDNI interfaces. Appendix B.2 describes the relationships between 
the CDNI problem space and other relevant IETF working groups and 
IRTF research groups. 


1.1. Terminology 
This document uses the following terms: 


Authoritative CDN: A CDN that has a direct relationship with a CSP 
for the distribution and delivery of that CSP's content by the 
Authoritative CDN or by Downstream CDNs of the Authoritative CDN. 


CDN Interconnection (CDNI): A relationship between a pair of CDNs 
that enables one CDN to provide content delivery services on behalf 
of another CDN. A CDN Interconnection may be wholly or partially 
realized through a set of interfaces over which a pair of CDNs 
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communicate with each other in order to achieve the delivery of 
content to User Agents by Surrogates in one CDN (the Downstream CDN) 
on behalf of another CDN (the Upstream CDN). 


CDN Provider: The service provider who operates a CDN and offers a 
service of content delivery, typically used by a Content Service 
Provider or another CDN Provider. Note that a given entity may 
operate in more than one role. For example, a company may 
simultaneously operate as a Content Service Provider, a Network 
Service Provider, and a CDN Provider. 


CDNI Metadata: The subset of Content Distribution Metadata that 

has an inter-CDN scope. For example, CDNI Metadata may include 
geo-blocking information (i.e., information defining geographical 
areas where the content is to be made available or blocked), 
availability windows (i.e., information defining time windows during 
which the content is to be made available or blocked) and access 
control mechanisms to be enforced (e.g., URI signature validation). 
CDNI Metadata may also include information about desired distribution 
policy (e.g., pre-positioned vs dynamic acquisition) and about where/ 
how a CDN can acquire the content. 


Content: Any form of digital data. One important form of Content 
with additional constraints on distribution and delivery is 
continuous media (i.e., where there is a timing relationship between 
source and sink). 


Content Distribution Metadata: The subset of Content Metadata that is 
relevant to the distribution of the content. This is the metadata 
required by a CDN in order to enable and control content distribution 
and delivery by the CDN. In a CDN Interconnection environment, some 
of the Content Distribution Metadata may have an intra-CDN scope (and 
therefore need not be communicated between CDNs), while some of the 
Content Distribution Metadata may have an inter-CDN scope (and 
therefore needs to be communicated between CDNs). 


Content Distribution Network (CDN) / Content Delivery Network (CDN): 
Network infrastructure in which the network elements cooperate at 
Layers 4 through 7 for more effective delivery of Content to User 
Agents. Typically, a CDN consists of a Request Routing system, a 
Distribution system (that includes a set of Surrogates), a Logging 
System, and a CDN Control system. 
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Content Metadata: This is metadata about Content. Content Metadata 
comprises: 


1. Metadata that is relevant to the distribution of the content (and 
therefore relevant to a CDN involved in the delivery of that 
content). We refer to this type of metadata as "Content 
Distribution Metadata". See also the definition of Content 
Distribution Metadata. 


2. Metadata that is associated with the actual Content or content 
representation, and not directly relevant to the distribution of 
that Content. For example, such metadata may include information 
pertaining to the Content's genre, cast, rating, etc. as well as 
information pertaining to the Content representation's 
resolution, aspect ratio, etc. 


Content Service: The service offered by a Content Service Provider. 
The Content Service encompasses the complete service, which may be 
wider than just providing access to items of Content; e.g., the 
Content Service also includes any middleware, key distribution, 
program guide, etc. that may not require any direct interaction with 
the CDN, or CDNs, involved in the distribution and delivery of the 


content. 
Content Service Provider (CSP): Provides a Content Service to End 
Users (which they access via a User Agent). A CSP may own the 


Content made available as part of the Content Service, or may license 
content rights from another party. 


Control system: The function within a CDN responsible for 
bootstrapping and controlling the other components of the CDN as well 
as for handling interactions with external systems (e.g., handling 
delivery service creation/update/removal requests, or specific 
service provisioning requests). 


Delivery: The function within CDN Surrogates responsible for 


delivering a piece of content to the User Agent. For example, 
delivery may be based on HTTP progressive download or HTTP adaptive 
streaming. 


Distribution system: The function within a CDN responsible for 
distributing Content Distribution Metadata as well as the Content 
itself inside the CDN (e.g., down to the Surrogates). 


Downstream CDN: For a given End User request, the CDN (within a pair 
of directly interconnected CDNs) to which the request is redirected 
by the other CDN (the Upstream CDN). Note that in the case of 
successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN 
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(e.g., CDN2) may act as the Downstream CDN for a redirection (e.g., 
CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection 
of the same request (e.g., CDN2-->CDN3). 


Dynamic CDNI Metadata acquisition: In the context of CDN 
Interconnection, dynamic CDNI Metadata acquisition means that a 
Downstream CDN acquires CDNI Metadata for content from the Upstream 
CDN at some point in time after a request for that content is 
delegated to the Downstream CDN by an Upstream CDN (and that specific 
CDNI Metadata is not yet available in the Downstream CDN). See also 
the definitions for Downstream CDN and Upstream CDN. 


Dynamic content acquisition: Dynamic content acquisition is where a 
CDN acquires content from the content source in response to an End 
User requesting that content from the CDN. In the context of CDN 
Interconnection, dynamic acquisition means that a Downstream CDN 
acquires the content from content sources (including Upstream CDNs) 
at some point in time after a request for that content is delegated 
to the Downstream CDN by an Upstream CDN (and that specific content 
is not yet available in the Downstream CDN). 


End User (EU): The 'real' user of the system, typically a human but 
maybe some combination of hardware and/or software emulating a human 
(e.g., for automated quality monitoring etc.). 


Logging system: The function within a CDN responsible for collecting 
the measurement and recording of distribution and delivery 
activities. The information recorded by the Logging system may be 
used for various purposes, including charging (e.g., of the CSP), 
analytics, and monitoring. 


Metadata: Metadata in general is data about data. 


Network Service Provider (NSP): Provides network-based connectivity/ 
services to End Users. 


Over-the-top (OTT): A service, e.g., content delivery using a CDN, 
operated by a different operator than the NSP to which the users of 
that service are attached. 


Pre-positioned CDNI Metadata acquisition: In the context of CDN 
Interconnection, CDNI Metadata pre-positioning is where the 
Downstream CDN acquires CDNI Metadata for content prior to, or 
independently of, any End User requesting that content from the 
Downstream CDN. 
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Pre-positioned content acquisition: Content pre-positioning is where 
a CDN acquires content from the content source prior to, or 
independently of, any End User requesting that content from the CDN. 
In the context of CDN Interconnection, the Upstream CDN instructs the 
Downstream CDN to acquire the content from content sources (including 
Upstream CDNs) in advance of, or independently of, any End User 
requesting it. 


Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390]. 


Request Routing system: The function within a CDN responsible for 
receiving a Content Request from a User Agent, obtaining and 
maintaining necessary information about a set of candidate Surrogates 
or candidate CDNs, and for selecting and redirecting the user to the 
appropriate Surrogate or CDN. To enable CDN Interconnection, the 
Request Routing system must also be capable of handling User Agent 
Content Requests passed to it by another CDN. 


Surrogate: À device/function (often called a cache) that interacts 
with other elements of the CDN for the control and distribution of 
Content within the CDN and interacts with User Agents for the 
delivery of the Content. Typically, Surrogates will cache requested 
content so that they can directly deliver the same content in 
response to requests from multiple User Agents (and their End Users), 
avoiding the need for the content to transit multiple times through 
the network core (i.e., from the content origin to the Surrogate). 


Upstream CDN: For a given End User request, the CDN (within a pair of 
directly interconnected CDNs) that redirects the request to the 
other CDN. 


User Agent (UA): Software (or a combination of hardware and software) 
through which the End User interacts with a Content Service. The 
User Agent will communicate with a Content Service for the selection 
of content and one or more CDNs for the delivery of the Content. 

Such communication is not restricted to HTTP and may be via a variety 
of protocols. Examples of User Agents (non-exhaustive) are browsers, 
Set Top Boxes (STBs), dedicated content applications (e.g., media 
players), etc. 
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1.2. CDN Background 


Readers are assumed to be familiar with the architecture, features, 
and operation of CDNs. For readers less familiar with the operation 
of CDNs, the following resources may be useful: 


o RFC 3040 [RFC3040] describes many of the component technologies 
that are used in the construction of a CDN. 


o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. 


o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 
IETF Content Distribution Internetworking (CDI) working group, 
which was closed in 2003. 


Note: Some of the terms used in this document are similar to terms 
used in the above referenced documents. When reading this document, 
terms should be interpreted as having the definitions provided in 
Section 1.1. 


2. CDN Interconnection Use Cases 


An increasing number of NSPs are deploying CDNs in order to deal 
cost-effectively with the growing usage of on-demand video services 
and other content delivery applications. 


CDNs allow caching of content closer to the edge of a network so that 
a given item of content can be delivered by a CDN Surrogate (i.e., a 
cache) to multiple User Agents (and their End Users) without 
transiting multiple times through the network core (i.e., from the 
content origin to the Surrogate). This contributes to bandwidth cost 
reductions for the NSP and to improved quality of experience for the 
End Users.  CDNs also enable replication of popular content across 
many Surrogates, which enables content to be served to large numbers 
of User Agents concurrently. This also helps in dealing with 
situations such as flash crowds and denial-of-service attacks. 


The CDNs deployed by NSPs are not just restricted to the delivery of 
content to support the Network Service Provider's own 'walled garden' 
Services, such as IP delivery of television services to Set Top 
Boxes, but are also used for delivery of content to other devices, 
including PCs, tablets, mobile phones, etc. 


Some service providers operate over multiple geographies and federate 
multiple affiliate NSPs. These NSPs typically operate independent 
CDNs. As they evolve their services (e.g., for seamless support of 
content services to nomadic users across affiliate NSPs), there is a 
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need for interconnection of these CDNs; this represents a first use 
case for CDNI. However, there are no open specifications, nor common 
best practices, defining how to achieve such CDN Interconnection. 


CSPs have a desire to be able to get (some of) their content to very 
large numbers of End Users, who are often distributed across a number 
of geographies, while maintaining a high quality of experience, all 
without having to maintain direct business relationships with many 
different CDN Providers (or having to extend their own CDN to a large 
number of locations). Some NSPs are considering interconnecting 
their respective CDNs (as well as possibly over-the-top CDNs) so that 
this collective infrastructure can address the requirements of CSPs 
in a cost-effective manner. This represents a second use case for 
CDNI. In particular, this would enable the CSPs to benefit from 
on-net delivery (i.e., within the Network Service Provider's own 
network/CDN footprint) whenever possible and off-net delivery 
otherwise, without requiring the CSPs to maintain direct business 
relationships with all the CDNs involved in the delivery. Again, CDN 
Providers (NSPs or over-the-top CDN operators) are faced with a lack 
of open specifications and best practices. 


NSPs have often deployed CDNs as specialized cost-reduction projects 
within the context of a particular service or environment. Some NSPs 
operate separate CDNs for separate services. For example, there may 
be a CDN for managed IPTV service delivery, a CDN for web-TV 
delivery, and a CDN for video delivery to mobile terminals. As NSPs 
integrate their service portfolio, there is a need for 
interconnecting these CDNs, representing a third use case for CDNI. 
Again, NSPs face the problem of lack of open interfaces for CDN 
Interconnection. 


For operational reasons (e.g., disaster, flash crowd) or commercial 
reasons, an over-the-top CDN may elect to make use of another CDN 
(e.g., an NSP CDN with on-net Surrogates for a given footprint) for 
serving a subset of the user requests (e.g., requests from users 
attached to that NSP), which results in a fourth use case for CDNI 
because CDN Providers (over-the-top CDN Providers or NSPs) are faced 
with a lack of open specifications and best practices. 


Use cases for CDN Interconnection are further discussed in 
[CDNI-USE-CASES]. 
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32 


CDN Interconnection Model and Problem Area for IETF 


This section discusses the problem area for the IETF work on CDN 
Interconnection. 


Interconnecting CDNs involves interactions among multiple different 
functions and components that form each CDN. Only some of those 
require additional specification by the IETF. 


Some NSPs have started to perform experiments to explore whether 
their CDN use cases can already be addressed with existing CDN 
implementations. One set of such experiments is documented in 
[CDNI-EXPERIMENTS]. The conclusions of those experiments are that 
while some basic limited CDN Interconnection functionality can be 
achieved with existing CDN technology, the current lack of any 
standardized CDNI interfaces with the necessary level of 
functionality such as those discussed in this document is preventing 
the deployment of CDN Interconnection. 


Listed below are the four interfaces required to interconnect a pair 
of CDNs and that constitute the problem space of CDN Interconnection 
along with the required functionality of each interface for which 
standards do not currently exist. As part of the development of the 
CDNI interfaces, it will also be necessary to agree on common 
mechanisms for how to identify and name the data objects that are to 
be interchanged between interconnected CDNs. 


The use of the term "interface" is meant to encompass the protocol 
over which CDNI data representations (e.g., CDNI Metadata objects) 
are exchanged as well as the specification of the data 
representations themselves (i.e., what properties/fields each object 
contains, its structure, etc.). 


o CDNI Control interface: This interface allows the "CDNI Control" 
system in interconnected CDNs to communicate. This interface may 
support the following: 


* Allow bootstrapping of the other CDNI interfaces (e.g., 
interface address/URL discovery and establishment of security 
associations). 


* Allow configuration of the other CDNI interfaces (e.g., 
Upstream CDN specifies information to be reported through the 
CDNI Logging interface). 


* Allow the Downstream CDN to communicate static (or fairly 
static) information about its delivery capabilities and 
policies. 
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* Allow bootstrapping of the interface between CDNs for content 
acquisition (even if that interface itself is outside the scope 
of the CDNI work). 


* Allow an Upstream CDN to initiate or request specific actions 
to be undertaken in the Downstream CDN. For example, to allow 
an Upstream CDN to initiate content or CDNI Metadata 
acquisition (pre-positioning) or to request the invalidation 
or purging of content files and/or CDNI Metadata in a 
Downstream CDN. 


CDNI Request Routing interface: This interface allows the Request 
Routing systems in interconnected CDNs to communicate to ensure 
that an End User request can be (re)directed from an Upstream CDN 
to a Surrogate in the Downstream CDN, in particular where 
selection responsibilities may be split across CDNs (for example, 
the Upstream CDN may be responsible for selecting the Downstream 
CDN, while the Downstream CDN may be responsible for selecting the 
actual Surrogate within that Downstream CDN). In particular, the 
functions of the CDN Request Routing interface may be divided as 
follows: 


* A CDNI Request Routing Redirection interface, which allows the 
Upstream CDN to query the Downstream CDN at request routing 
time before redirecting the request to the Downstream CDN. 


* A CDNI Footprint & Capabilities advertisement interface, which 
allows the Downstream CDN to provide to the Upstream CDN 
(static or dynamic) information (e.g., resources, footprint, 
load) to facilitate selection of the Downstream CDN by the 
Upstream CDN Request Routing system when processing subsequent 
Content Requests from User Agents. 


CDNI Metadata interface: This interface allows the Distribution 
System in interconnected CDNs to communicate to ensure that CDNI 
Metadata can be exchanged across CDNs. See Section 1.1 for the 
definition and examples of CDNI Metadata. 


CDNI Logging interface: This interface allows the Logging system 
in interconnected CDNs to communicate the relevant activity logs 
in order to allow log-consuming applications to operate in a 
multi-CDN environment. For example, an Upstream CDN may collect 
delivery logs from a Downstream CDN in order to perform 
consolidated charging of the CSP or for settlement purposes across 
CDNs. Similarly, an Upstream CDN may collect delivery logs from a 
Downstream CDN in order to provide consolidated reporting and 
monitoring to the CSP. 
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Note that the actual grouping of functionalities under these four 
interfaces is considered tentative at this stage and may be changed 
after further study (e.g., some subset of functionality may be moved 
from one interface into another). 


The above list covers a significant potential problem space, in part 
because in order to interconnect two CDNs there are several 'touch 
points’ that require standardization. However, it is expected that 
the CDNI interfaces need not be defined from scratch and instead can 
reuse or leverage existing protocols to a very significant extent; 
this is discussed further in Section 4. 


The interfaces that form the CDNI problem area are illustrated in 
Figure 1. 
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Figure 1: A Model for the CDNI 
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As illustrated in Figure 1, the acquisition of content between 
interconnected CDNs is out of scope for CDNI; this deserves some 
additional explanation. The consequence of such a decision is that 
the CDNI problem space described in this document is focused on only 
defining the control plane for CDNI, and the CDNI data plane (i.e., 
the acquisition and distribution of the actual content objects) is 
out of scope. The rationale for such a decision is that CDNs today 
typically already use standardized protocols such as HTTP, FTP, 
rsync, etc. to acquire content from their CSP customers, and it is 
expected that the same protocols could be used for acquisition 
between interconnected CDNs. Therefore, the problem of content 
acquisition is considered already solved, and all that is required 
with respect to content acquisition from specifications developed by 
the CDNI working group is to describe within the CDNI Metadata the 
parameters to use to retrieve the content -- for example, the IP 
address/hostname to connect to, what protocol to use to retrieve the 
content, etc. 


4. Scoping the CDNI Problem 


This section outlines how the scope of work addressing the CDNI 
problem space can be constrained through reuse or leveraging of 
existing protocols to implement the CDNI interfaces. This discussion 
is not intended to preempt any working group decision as to the most 
appropriate protocols, technologies, and solutions to select to 
realize the CDNI interfaces but is intended as an illustration of the 
fact that the CDNI interfaces need not be created in a vacuum and 
that reuse or leverage of existing protocols is likely possible. 


The four CDNI interfaces (CDNI Control interface, CDNI Request 
Routing interface, CDNI Metadata interface, and CDNI Logging 
interface) described in Section 3 within the CDNI problem area are 
all control plane interfaces operating at the application layer 
(Layer 7 in the OSI network model). Firstly, since it is not 
expected that these interfaces would exhibit unique session, 
transport, or network requirements as compared to the many other 
existing applications in the Internet, it is expected that the CDNI 
interfaces will be defined on top of existing session, transport, and 
network protocols. 


Secondly, although a new application protocol could be designed 
Specifically for CDNI, our analysis below shows that this is 
unnecessary, and it is recommended that existing application 
protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing 
Protocol [RFC5023], the Extensible Messaging and Presence Protocol 
(XMPP) [RFC6120], for example) to realize the CDNI interfaces. 
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4.1. CDNI Control Interface 


The CDNI Control interface allows the Control system in 
interconnected CDNs to communicate. The exact inter-CDN control 
functionality required to be supported by the CDNI Control interface 
is less well defined than the other three CDNI interfaces at this 
time. 


It is expected that for the Control interface, as for the other CDNI 
interfaces, existing protocols can be reused or leveraged. 


4.2.  CDNI Request Routing Interface 


The CDNI Request Routing interface enables a Request Routing function 
in an Upstream CDN to query a Request Routing function in a 
Downstream CDN to determine if the Downstream CDN is able (and 
willing) to accept the delegated Content Request. It also allows the 
Downstream CDN to control what should be returned to the User Agent 
in the redirection message by the upstream Request Routing function. 


The CDNI Request Routing interface is therefore a fairly 
straightforward request/response interface and could be implemented 
over any number of request/response protocols. For example, it may 
be implemented as a WebService using one of the common WebServices 
methodologies (Extensible Markup Language-Remote Procedure Calling 
(XML-RPC), HTTP query to a known URI, etc.). This removes the need 
for the CDNI working group to define a new protocol for the request/ 
response element of the CDNI Request Routing interface. 


Additionally, as discussed in Section 3, the CDNI Request Routing 
interface is also expected to enable a Downstream CDN to provide to 
the Upstream CDN (static or dynamic) information (e.g., resources, 
footprint, load) to facilitate selection of the Downstream CDN by the 
Upstream CDN Request Routing system when processing subsequent 
Content Requests from User Agents. It is expected that such 
functionality of the CDNI request routing could be specified by the 
CDNI working group with significant leveraging of existing IETF 
protocols supporting the dynamic distribution of reachability 
information (for example, by leveraging existing routing protocols) 
or supporting application-level queries for topological information 
(for example, by leveraging Application-Layer Traffic Optimization 
(ALTO) [RFC5693]). 
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4.3. CDNI Metadata Interface 


The CDNI Metadata interface enables the Distribution system in a 
Downstream CDN to request CDNI Metadata from an Upstream CDN so that 
the Downstream CDN can properly process and respond to redirection 
requests received over the CDNI Request Routing interface and Content 
Requests received directly from User Agents. 


The CDNI Metadata interface is therefore similar to the CDNI Request 
Routing interface because it is a request/response interface with the 
potential addition that CDNI Metadata search may have more complex 
semantics than a straightforward Request Routing redirection request. 
Therefore, like the CDNI Request Routing interface, the CDNI Metadata 
interface may be implemented as a WebService using one of the common 
WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 
or possibly using other existing protocols such as XMPP [RFC6120]. 
This removes the need for the CDNI working group to define a new 
protocol for the request/response element of the CDNI Metadata 
interface. 


4.4. CDNI Logging Interface 


The CDNI Logging interface enables details of content distribution 
and delivery activities to be exchanged between interconnected CDNs 
-- for example, the exchange of log records related to the delivery 
of content, similar to the log records recorded in a web server's 
access log. 


Several protocols already exist that could potentially be used to 
exchange CDNI logs between interconnected CDNs, including the Simple 
Network Management Protocol (SNMP), syslog, FTP (and secure 
variants), HTTP POST, etc. 


5. Security Considerations 


Distribution of content by a CDN comes with a range of security 
considerations, such as how to enforce control of access to the 
content by End Users in line with the CSP policy, or how to trust the 
logging information generated by the CDN for the purposes of charging 
the CSP. These security aspects are already dealt with by CDN 
Providers and CSPs today in the context of standalone CDNs. However, 
interconnection of CDNs introduces a new set of security 
considerations by extending the trust model to a chain of trust 
(i.e., the CSP "trusts" a CDN that "trusts" another CDN). The 
mechanisms used to mitigate these risks in multi-CDN environments may 
be similar to those used in the single-CDN case, but their 
suitability in this more complex environment must be validated. 
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The interconnection of CDNs may also introduce additional privacy 
considerations on top of those that apply to the single-CDN case. In 
a multi-CDN environment, the different CDNs may reside in different 
legal regimes that require differing privacy requirements to be 
enforced. Such privacy requirements may impact the granularity of 
information that can be exchanged across the CDNI interfaces. For 
example, the Logging system in a Downstream CDN may need to apply 
some degree of anonymization, obfuscation, or even the complete 
removal of some fields before exchanging log records containing 
details of End User deliveries with an Upstream CDN. 


Maintaining the security of the content itself, its associated 
metadata (including delivery policies), and the CDNs distributing and 
delivering it, are critical requirements for both CDN Providers and 
CSPs, and the CDN Interconnection interfaces must provide sufficient 
mechanisms to maintain the security of the overall system of 
interconnected CDNs as well as the information (content, metadata, 
logs, etc.) distributed and delivered through any set of 
interconnected CDNs. 


5.1. Security of the CDNI Control Interface 


Information exchanged between interconnected CDNs over this interface 
is of a sensitive nature. A pair of CDNs use this interface to allow 
bootstrapping of all the other CDNI interfaces, possibly including 
establishment of the mechanisms for securing these interfaces. 
Therefore, corruption of that interface may result in corruption of 
all other interfaces. Using this interface, an Upstream CDN may 
pre-position or delete content or metadata in a Downstream CDN, a 
Downstream CDN may provide administrative information to an Upstream 
CDN, etc. All of these operations require that the peer CDNs are 
appropriately authenticated and that the confidentiality and 
integrity of information flowing between them can be ensured. 


5.2. Security of the CDNI Request Routing Interface 


Appropriate levels of authentication and confidentiality must be used 
in this interface because it allows an Upstream CDN to query the 
Downstream CDN in order to redirect requests, and conversely, allows 
the Downstream CDN to influence the Upstream CDN's Request Routing 
function. 


In the absence of appropriate security on this interface, a rogue 
Upstream CDN could inundate Downstream CDNs with bogus requests or 
have the Downstream CDN send the rogue Upstream CDN private 
information. Also, a rogue Downstream CDN could influence the 
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Upstream CDN so the Upstream CDN redirects requests to the rogue 
Downstream CDN or another Downstream CDN in order to, for example, 
attract additional delivery revenue. 


5.3. Security of the CDNI Metadata Interface 


This interface allows a Downstream CDN to request CDNI Metadata from 
an Upstream CDN, and therefore the Upstream CDN must ensure that the 
former is appropriately authenticated before sending the data. 
Conversely, a Downstream CDN must authenticate an Upstream CDN before 
requesting metadata to insulate itself from poisoning by rogue 
Upstream CDNs. The confidentiality and integrity of the information 
exchanged between the peers must be protected. 


5.4. Security of the CDNI Logging Interface 


Logging data consists of potentially sensitive information (which End 
User accessed which media resource, IP addresses of End Users, 
potential names and subscriber account information, etc.). 
Confidentiality of this information must be protected as log records 
are moved between CDNs. This information may also be sensitive from 
the viewpoint that it can be the basis for charging across CDNs. 
Therefore, appropriate levels of protection are needed against 
corruption, duplication, and loss of this information. 
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Appendix A. Design Considerations for Realizing the CDNI Interfaces 


This section expands on how CDNI interfaces can reuse and leverage 
existing protocols before describing each CDNI interface individually 
and highlighting example candidate protocols that could be considered 
for reuse or leveraging to implement the CDNI interfaces. However, 
the options discussed here are purely examples and do not present any 
consensus on protocols to be used later on. 


A.1. CDNI Control Interface 


The CDNI Control interface allows the Control system in 
interconnected CDNs to communicate. The exact inter-CDN control 
functionality required to be supported by the CDNI Control interface 
is less well defined than the other three CDNI interfaces at this 
time. 


However, as discussed in Section 3, the CDNI Control interface may be 
required to support functionality similar to the following: 


o Allow an Upstream CDN and Downstream CDN to establish, update, or 
terminate their CDNI interconnection. 


o Allow bootstrapping of the other CDNI interfaces (e.g., protocol 
address discovery and establishment of security associations). 


o Allow configuration of the other CDNI interfaces (e.g., Upstream 
CDN specifies information to be reported through the CDNI Logging 
interface). 


o Allow the Downstream CDN to communicate static information about 
its delivery capabilities, resources, and policies. 


o Allow bootstrapping of the interface between CDNs for content 
acquisition (even if that interface itself is outside the scope of 
the CDNI work). 


It is expected that for the Control interface, as for the other CDNI 
interfaces, existing protocols can be reused or leveraged. Those 
will be considered once the requirements for the Control interface 
have been refined. 
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A.2.  CDNI Request Routing Interface 


The CDNI Request Routing interface enables a Request Routing function 
in an Upstream CDN to query a Request Routing function in a 
Downstream CDN to determine if the Downstream CDN is able (and 
willing) to accept the delegated Content Request and to allow the 
Downstream CDN to control what the upstream Request Routing function 
should return to the User Agent in the redirection message. 


Therefore, the CDNI Request Routing interface needs to offer a 
mechanism for an Upstream CDN to issue a "Redirection Request" to a 
Downstream CDN. The Request Routing interface needs to be able to 
support scenarios where the initial User Agent request to the 
Upstream CDN is received over DNS as well as over a content-specific 
application protocol (e.g., HTTP, the Real Time Streaming Protocol 
(RTSP), the Real Time Messaging Protocol (RTMP), etc.). 


Therefore, a Redirection Request is expected to contain information 
such as: 


o The protocol (e.g., DNS, HTTP) over which the Upstream CDN 
received the initial User Agent request. 


o Additional details of the User Agent request that are required to 
perform effective Request Routing by the Downstream CDN. For DNS, 
this would typically be the IP address of the DNS resolver making 
the request on behalf of the User Agent. For requests received 
over content-specific application protocols, the Redirection 
Request could contain significantly more information related to 
the original User Agent request but at a minimum is expected to 
include the User Agent's IP address, the equivalent of the HTTP 
Host header, and the equivalent of the HTTP abs path as defined in 
[RFC2616]. 


It should be noted that the CDNI architecture needs to consider that 
a Downstream CDN may receive requests from User Agents without first 
receiving a Redirection Request from an Upstream CDN for the 
corresponding User Agent request because, for example: 


o User Agents (or DNS resolvers) may cache DNS or application 
responses from Request Routers. 


o Responses to Redirection Requests over the Request Routing 
interface may be cacheable. 
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o Some CDNs may rely on simple coarse policies, e.g., CDN B agrees 
to always serve CDN A's delegated redirection requests, in which 
case the necessary redirection details are exchanged out of band 
(of the CDNI interfaces), e.g., configured. 


On receiving a Redirection Request, the Downstream CDN will use the 

information provided in the request to determine if it is able (and 

willing) to accept the delegated Content Request and needs to return 
the result of its decision to the Upstream CDN. 


Thus, a Redirection Response from the Downstream CDN is expected to 
contain information such as: 


o Status code indicating acceptance or rejection (possibly with 
accompanying reasons). 


o Information to allow redirection by the Upstream CDN. In the case 
of DNS-based request routing, this is expected to include the 
equivalent of a DNS record(s) (e.g., a CNAME) that the Upstream 
CDN should return to the requesting DNS resolver. In the case of 
application-based request routing, this is expected to include the 
information necessary to construct the application-specific 
redirection response(s) to return to the requesting User Agent. 
For HTTP requests from User Agents, this could include a URI that 
the Upstream CDN could return in an HTTP 3xx response. 


The CDNI Request Routing interface is therefore a fairly 
straightforward request/response interface and could be implemented 
over any number of request/response protocols. For example, it may 
be implemented as a WebService using one of the common WebServices 
methodologies (XML-RPC, HTTP query to a known URI, etc.). This 
removes the need for the CDNI working group to define a new protocol 
for the request/response element of the CDNI Request Routing 
interface. Thus, the CDNI working group would be left only with the 
task of specifying: 


o The recommended request/response protocol to use along with any 
additional semantics and procedures that are specific to the CDNI 
Request Routing interface (e.g., handling of malformed requests/ 
responses). 


o The syntax (i.e., representation/encoding) of the redirection 
requests and responses. 


o The semantics (i.e., meaning and expected contents) of the 
redirection requests and responses. 
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Additionally, as discussed in Section 3, the CDNI Request Routing 
interface is also expected to enable a Downstream CDN to provide to 
the Upstream CDN (static or dynamic) information (e.g., resources, 
footprint, load) to facilitate selection of the Downstream CDN by the 
Upstream CDN Request Routing system when processing subsequent 
Content Requests from User Agents. It is expected that such 
functionality of the CDNI request routing could be specified by the 
CDNI working group with significant leveraging of existing IETF 
protocols supporting the dynamic distribution of reachability 
information (for example, by leveraging existing routing protocols) 
or supporting application-level queries for topological information 
(for example, by leveraging ALTO). 


A.3. CDNI Metadata Interface 


The CDNI Metadata interface enables the Distribution system in a 
Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that 
the Downstream CDN can properly process and respond to: 


o Redirection Requests received over the CDNI Request Routing 
interface. 


o Content Requests received directly from User Agents. 


The CDNI Metadata interface needs to offer a mechanism for an 
Upstream CDN to: 


o Distribute/update/remove CDNI Metadata to a Downstream CDN. 
and/or to allow a Downstream CDN to: 
o Make direct requests for CDNI Metadata objects. 


o Make recursive requests for CDNI Metadata -- for example, to 
enable a Downstream CDN to walk down a tree of objects with 
inter-object relationships. 


The CDNI Metadata interface is therefore similar to the CDNI Request 
Routing interface because it is a request/response interface with the 
potential addition that CDNI Metadata search may have more complex 
semantics than a straightforward Request Routing redirection request. 
Therefore, like the CDNI Request Routing interface, the CDNI Metadata 
interface may be implemented as a WebService using one of the common 
WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 
or possibly using other existing protocols such as XMPP [RFC6120]. 
This removes the need for the CDNI working group to define a new 
protocol for the request/response element of the CDNI Metadata 
interface. 
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Thus, the CDNI working group would be left only with the task of 
specifying: 


o The recommended request/response protocol to use along with any 
additional semantics that are specific to the CDNI Metadata 
interface (e.g., handling of malformed requests/responses). 


o The syntax (i.e., representation/encoding) of the CDNI Metadata 
objects that will be exchanged over the interface. 


o The semantics (i.e., meaning and expected contents) of the 
individual properties of a Metadata object. 


o How the relationships between different CDNI Metadata objects are 
represented. 


A.4.  CDNI Logging Interface 


The CDNI Logging interface enables details of content distribution 
and delivery activities to be exchanged between interconnected CDNs, 
such as log records related to the delivery of content (similar to 
the log records recorded in a web server's access log). 


Within CDNs today, log records are used for a variety of purposes. 
Specifically, CDNs use logs to generate Call Data Records (CDRs) for 
passing to billing and payment systems and to real-time (and near 
real-time) analytics systems. Such applications place requirements 
on the CDNI Logging interface to support guaranteed and timely 
delivery of log messages between interconnected CDNs. It may also be 
necessary to be able to prove the integrity of received log messages. 


Several protocols already exist that could potentially be used to 
exchange CDNI logs between interconnected CDNs, including SNMP traps, 
syslog, FTP, HTTP POST, etc., although it is likely that some of the 
candidate protocols may not be well suited to meet all the 
requirements of CDNI. For example, SNMP traps pose scalability 
concerns, and SNMP does not support guaranteed delivery of traps and 
therefore could result in log records being lost and the consequent 
CDRs and billing records for that content delivery not being 
produced, as well as that content delivery being invisible to any 
analytics platforms. 
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Although it is not necessary to define a new protocol for exchanging 
logs across the CDNI Logging interface, the CDNI working group would 
Still need to specify: 


o 


o 


o 


The recommended protocol to use. 


A default set of log fields and of their syntax and semantics. 
Today there is no standard set of common log fields across 
different content delivery protocols, and in some cases there is 
not even a standard set of log field names and values for 
different implementations of the same delivery protocol. 


A default set of conditions that trigger log records to be 
generated. 


Appendix B. Additional Material 


B. 


This section records related information that was produced as part of 
defining the CDNI problem statement. 


d. 


Non-Goals for IETF 


Listed below are aspects of content delivery that the authors propose 
be kept outside of the scope of the CDNI working group: 


o 


The interface between the Content Service Provider and the 
Authoritative CDN (i.e., the Upstream CDN contracted by the CSP 
for delivery by this CDN or by its Downstream CDNs). 


The delivery interface between the delivering CDN Surrogate and 
the User Agent, such as streaming protocols. 


The request interface between the User Agent and the Request 
Routing system of a given CDN. Existing IETF protocols (e.g., 
HTTP, RTSP, DNS) are commonly used by User Agents to request 
content from a CDN and by CDN Request Routing systems to redirect 
the User Agent requests. The CDNI working group need not define 
new protocols for this purpose. Note, however, that the CDNI 
control plane interface may indirectly affect some of the 
information exchanged through the request interface (e.g., URI). 


The content acquisition interface between CDNs (i.e., the data 
plane interface for actual delivery of a piece of content from one 
CDN to the other). This is expected to use existing protocols 
such as HTTP or protocols defined in other forums for content 
acquisition between an origin server and a CDN (e.g., HTTP-based 
C2 reference point of the Alliance for Telecommunications Industry 
Solutions IPTV Interoperability Forum Content on Demand service 
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(ATIS IIF CoD)). The CDN Interconnection problem space described 
in this document may therefore only concern itself with the 
agreement/negotiation aspects of which content acquisition 
protocol is to be used between two interconnected CDNs in view of 
facilitating interoperability. 


o End User/User Agent Authentication. End User/User Agent 
authentication and authorization are the responsibility of the 
Content Service Provider. 


o Content preparation, including encoding and transcoding. The CDNI 
architecture aims at allowing distribution across interconnected 
CDNs of content treated as opaque objects. Interpretation and 
processing of the objects, as well as optimized delivery of these 
objects by the Surrogate to the End User, are outside the scope of 
CDNI. 


o Digital Rights Management (DRM). DRM is an end-to-end issue 
between a content protection system and the User Agent. 


o Applications consuming CDNI logs (e.g., charging, analytics, 
reporting, ...). 


o Internal CDN interfaces and protocols (i.e., interfaces and 
protocols within one CDN). 


o Scalability of individual CDNs. While scalability of the CDNI 
interfaces/approach is in scope, how an individual CDN scales is 
out of scope. 


o Actual algorithms for selection of CDNs or Surrogates by Request 
Routing systems (however, some specific parameters required as 
input to these algorithms may be in scope when they need to be 
communicated across CDNs). 


o Surrogate algorithms. For example, caching algorithms and content 
acquisition methods are outside the scope of the CDNI work. 
Content management (e.g., Content Deletion) as it relates to CDNI 
content management policies is in scope, but the internal 
algorithms used by a cache to determine when to no longer cache an 
item of Content (in the absence of any specific metadata to the 
contrary) is out of scope. 


o Element management interfaces. 


o Commercial, business, and legal aspects related to the 
interconnections of CDNs. 
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B.2. Relationship to Relevant IETF Working Groups and IRTF Research 
Groups 


B.2.1. ALTO WG 
As stated in the ALTO working group charter [ALTO-Charter]: 


The Working Group will design and specify an Application-Layer 
Traffic Optimization (ALTO) service that will provide applications 
with information to perform better-than-random initial peer 
selection. ALTO services may take different approaches at 
balancing factors such as maximum bandwidth, minimum cross-domain 
traffic, lowest cost to the user, etc. The working group will 
consider the needs of BitTorrent, tracker-less P2P, and other 
applications, such as content delivery networks (CDN) and mirror 
selection. 


In particular, the ALTO service can be used by a CDN Request Routing 
system to improve its selection of a CDN Surrogate to serve a 
particular User Agent request (or to serve a request from another 
Surrogate). [ALTO-CDN-USE-CASES] describes a number of use cases for 
a CDN to be able to obtain network topology and cost information from 
an ALTO server(s) and discusses how CDN Request Routing could be used 
as an integration point of ALTO into CDNs. It is possible that the 
ALTO service could be used in the same manner in a multi-CDN 
environment based on CDN Interconnection. For example, an Upstream 
CDN may take advantage of the ALTO service in its decision for 
selecting a Downstream CDN to which a user request should be 
delegated. 


However, the current work of ALTO is complementary to and does not 
overlap with the work described in this document because the 
integration between ALTO and a CDN is an internal decision for a 
specific CDN and is therefore out of scope for the CDNI working 
group. One area for further study is whether additional information 
should be provided by an ALTO service to facilitate CDNI CDN 
selection. 


B.2.2.  DECADE WG 


The DECADE working group [DECADE-Charter] is addressing the problem 
of reducing traffic on the last-mile uplink, as well as backbone and 
transit links caused by peer-to-peer (P2P) streaming and file-sharing 
applications. It addresses the problem by enabling an application 
endpoint to make content available from an in-network storage service 
and by enabling other application endpoints to retrieve the content 
from there. 
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Exchanging data through the in-network storage service in this 
manner, instead of through direct communication, provides significant 
gain where: 


o The network capacity/bandwidth from the in-network storage service 
to the application endpoint significantly exceeds the capacity/ 
bandwidth from application endpoint to application endpoint (e.g., 
because of an end-user uplink bottleneck); and 


o The content is to be accessed by multiple instances of application 
endpoints (e.g., as is typically the case for P2P applications). 


While, as is the case for any other data distribution application, 
the DECADE architecture and mechanisms could potentially be used for 
exchange of CDNI control plane information via an in-network storage 
service (as opposed to directly between the entities terminating the 
CDNI interfaces in the neighbor CDNs), we observe that: 


o CDNI would operate as a "Content Distribution Application" from 
the DECADE viewpoint (i.e., would operate on top of DECADE). 


o There do not seem to be obvious benefits in integrating the DECADE 
control plane responsible for signaling information relating to 
control of the in-network storage service itself, and the CDNI 
control plane responsible for application-specific CDNI 
interactions (such as exchange of CDNI Metadata, CDNI request 
redirection, and transfer of CDNI logging information). 


o There would typically be limited benefits in making use of a 
DECADE in-network storage service because the CDNI interfaces are 
expected to be terminated by a very small number of CDNI clients 
(if not one) in each CDN, and the CDNI clients are expected to 
benefit from high bandwidth/capacity when communicating directly 
to each other (at least as high as if they were communicating via 
an in-network storage server). 


The DECADE in-network storage architecture and mechanisms may 
theoretically be used for the acquisition of the content objects 
themselves between interconnected CDNs. It is not expected that this 
would have obvious benefits in typical situations where a content 
object is acquired only once from an Upstream CDN to a Downstream CDN 
(and then distributed as needed inside the Downstream CDN). But it 
might have benefits in some particular situations. Since the 
acquisition protocol between CDNs is outside the scope of the CDNI 
work, this question is left for further study. 
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The DECADE in-network storage architecture and mechanisms may 
potentially also be used within a given CDN for the distribution of 
the content objects themselves among Surrogates of that CDN. Since 
the CDNI work does not concern itself with operation within a CDN, 
this question is left for further study. 


Therefore, the work of DECADE may be complementary to, but does not 
overlap with, the CDNI work described in this document. 


Bs23345 PPSP WG 
As stated in the PPSP working group charter [PPSP-Charter]: 


The Peer-to-Peer Streaming Protocol (PPSP) working group develops 
two signaling and control protocols for a peer-to-peer (P2P) 
Streaming system for transmitting live and time-shifted media 
content with near real-time delivery requirements... 


The PPSP working group designs a protocol for signaling and 
control between trackers and peers (the PPSP "tracker protocol") 
and a signaling and control protocol for communication among the 
peers (the PPSP "peer protocol"). The two protocols enable peers 
to receive streaming data within the time constraints required by 
Specific content items. 


Therefore, PPSP is concerned with the distribution of the streamed 
content itself along with the necessary signaling and control 
required to distribute the content. As such, it could potentially be 
used for the acquisition of streamed content across interconnected 
CDNs. But since the acquisition protocol is outside the scope of the 
work proposed for CDNI, we leave this for further study. Also, 
because of its streaming nature, PPSP is not seen as applicable to 
the distribution and control of the CDNI control plane and CDNI data 
representations. 


Therefore, the work of PPSP may be complementary to, but does not 
overlap with, the work described in this document for CDNI. 


B.2.4. IRTF P2P Research Group 
Some information on CDN Interconnection motivations and technical 


issues were presented in the P2P research group at IETF 77. The 
presentation can be found in [P2PRG-CDNI]. 
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